Troubleshooting and problem resolution pose a similar challenge: compressing large amounts of documentation, experience and information into an organized, coherent repository of knowledge and expertise. The same challenge exists in other types of knowledge-intensive processes, such as design, advice, consulting, guidance, and decision-making. In the following, the term ‘problem resolution’ is mean to include all such processes.
In troubleshooting and problem resolution, if expertise is not shared, the same problem that an expert solves immediately might ultimately have to be solved by a less-experienced person, after much wasted effort, time and resources.
Since experts are difficult to find, the goal has always been to let the expert's capabilities be shared by the less experienced engineers through methods such as formal and on-the-job training, mentor sponsorships, etc., and involving the expert in the production of the troubleshooting manuals. All of these methods place a demand on the expert's time. Furthermore, not always the most outstanding engineer is also the best instructor of new service persons or any other qualified personnel.
A more direct approach involves equipping each qualified engineer with “packaged knowledge” in the form of problem resolution software. By replicating the knowledge, it is possible to supply each engineer with the organization's combined troubleshooting expertise.
With this approach, the question becomes how to find the knowledge, and how to introduce it into the problem resolution software. After all, the essential problem is that a few available experts are overloaded by the need to support the whole organization. It would be impractical to attempt to solve the dilemma by asking the experts to spend months computerizing their knowledge, also because problems are solved as they present themselves, and may be difficult to remember and characterize at a distance in time.
Two prevalent methods of eliciting and organizing diagnostics expertise are the model-based method—which asks the expert to specify the components, functions, possible symptoms and available repair for the unit being serviced, and the case-based method, which relies on collecting cases (wherein each case includes the original symptom, the fact-finding or repair actions undertaken by the service engineer, and the problem resolution). By looking closely into the requirements of problem resolution software, we find that both methods play important roles. We also find that both methods share the problem discussed here: getting knowledge into the expert system.
Just as no human becomes an expert effortlessly, neither can a software expert system acquire all knowledge immediately. Information has to be input before we can get anything out. Therefore, a knowledge-based system might be a suitable solution.